home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group00a.txt / 000038_icon-group-sender _Mon Feb 28 12:41:59 2000.msg < prev    next >
Internet Message Format  |  2001-01-03  |  1KB
  1. Return-Path: <icon-group-sender>
  2. Received: (from root@localhost)
  3.     by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA14946
  4.     for icon-group-addresses; Mon, 28 Feb 2000 12:41:09 -0700 (MST)
  5. Message-Id: <200002281941.MAA14946@baskerville.CS.Arizona.EDU>
  6. Date: Mon, 28 Feb 2000 08:46:18 -0700
  7. From: Steve Wampler <swampler@noao.edu>
  8. X-Accept-Language: en
  9. To: jeffery@big-bill.CS.UNLV.EDU,
  10.         icon-group <icon-group@optima.CS.Arizona.EDU>
  11. Subject: Re: closing a closed file
  12. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  13. Status: RO
  14.  
  15. jeffery@big-bill.CS.UNLV.EDU wrote:
  16. > 
  17. > The Icon book doesn't say what happens when you close a closed file, but
  18. > some real applications assume that it is a no-op.  On my Redhat/Mandrake
  19. > Linux system, the following program causes a memory violation in the
  20. > reference to &clock.
  21. > 
  22. > procedure main()
  23. >    f := open("foo.icn")
  24. >    close(f)
  25. >    close(f)
  26. >    &clock
  27. > end
  28. > 
  29. > So closing a closed file is a silent killer on some systems. The bug is tiny
  30. > and the fix in Icon's runtime system is trivial, but at present you may wish
  31. > to avoid closing closed files.
  32.  
  33. Interesting.  I don't see this under Solis (Icon 9.3) or on one Redhat 6.1
  34. (Icon 9.3.2) system, but I do see this on another RH6.1 system (Icon 9.3.1).
  35.  
  36. I would have expected it to be a no-op, also.  
  37.  
  38. --
  39. Steve Wampler-  SOLIS Project, National Solar Observatory
  40. swampler@noao.edu
  41.